Electronic design automation tools help assess a design of an electronic system in terms of its functionality, performance, and cost. A virtual electronic system used by the automation tools is generally composed of functional models, communication models, and architectural models. Each of these models is associated with a specific performance model. Virtual architecture components are usually implemented as services with one or more layers. In this context, evaluating a single implementation of an embedded system requires considering data from a simulation of a large number of design items characterized by a large number of metrics. It rapidly becomes impossible to collect information about the items at every clock tick during the simulation, then correlate the collected information from different levels and designs during post-processing analysis.
An application program for a system-level design, such as a video system for example, produces Gigabytes of data during simulation runs. Also, the number of input-output (I/O) operations needed to collect this data often makes the speed of the simulation impractical. There is a need for reference keys that would uniquely identify the execution contexts of execution at the application-level. There is also a need to perform in-depth analysis of models based on the relationship between events that occur in a system's high level design and their decomposition into multiple reactions of lower-level system components by propagating trigger signals to potentially all models However, a commonly accepted system design paradigm assumes a clear separation between functional and performance models, as well as an orthogonal arrangement of architecture services. Therefore, the conventional paradigm does not facilitate the vertical propagation of triggering signals through several layers of models.
For example, a probing capability already exists in modem simulators, but the probes are time driven. They cannot be synchronized dynamically, but instead are synchronized statically prior to a simulation. The probes usually collect data during the entire simulation, from beginning to end. Sometimes, the activation of the probe is delayed by a given amount of time after the start time to postpone the probe activation. An end time can also be set to stop the probe from collecting data before the end of the simulation. However, these data collection periods are fixed prior to executing the simulation. Therefore, the probes cannot be controlled by events that occur during a simulation run. Also, it is not possible to clearly define different levels of probing using existing methods. Output data cannot be correlated with functional events. Furthermore, seamless probing through several service layers during a simulation of a system is not possible because of a probe's lack of synchronization to other probes and a lack of a common reference for the probes.